Pid 1151 DASM Question...

[aivikrames]

Ok, so I have been disassembling this 167 bin file and I have quick question to see if I am calculating the forumla for pid 1151 correctly:

------------------------------------------------------------------------
Line1: move.w ($FFFFA390).w,d0
Line2: mulu.w #$D,d0
Line3: divu.w #$105,d0
Line4: rts
------------------------------------------------------------------------

this is the routine for PID 1151, this is how I am calculating it right now:

Line 1 = $FFFFA390 = (TPS% * 256)
Line 2 = x 13
Line 3 = / 261
Line 4 = Returns: x 12.75

Is my math correct? Also are all the initial variables to start, for exampe $FFFFA390 or $FFFF9BD4 (EGR Duty Cycle), multiplied by 256?


Thanks,

Tim

[FastFieros]

Hi Tim,

What ROM location is that at?

Also, what is the OS ID number of the L67 bin?

I have made no progress on the disassembly of the PID and DTC's.

Loyde

[Chris@HPTuners]

Ok, so I have been disassembling this 167 bin file and I have quick question to see if I am calculating the forumla for pid 1151 correctly:

------------------------------------------------------------------------
Line1: move.w ($FFFFA390).w,d0
Line2: mulu.w #$D,d0
Line3: divu.w #$105,d0
Line4: rts
------------------------------------------------------------------------

this is the routine for PID 1151, this is how I am calculating it right now:

Line 1 = $FFFFA390 = (TPS% * 256)
Line 2 = x 13
Line 3 = / 261
Line 4 = Returns: x 12.75

Is my math correct? Also are all the initial variables to start, for exampe $FFFFA390 or $FFFF9BD4 (EGR Duty Cycle), multiplied by 256?


Thanks,

Tim

Firstly, you need to know the output scaling of the values that come in the PIDs. For TPS% i can tell you that it is a single byte that ranges from 0-100%. So you know that a raw value of 255 = 100% TPS. Then you just work backwards to work out the RAM scalar. eg. for TPS it works out as (255/100) * 261 / 13 = 51.2

So in RAM the PCM stores the TPS% value as x 51.2 (ie. 100% = 5120 ($1400)

Generally it is easy to see the maximum value of various RAM values in the code as there is a lot of range checking.

[aivikrames]

Chris thanks for the reply. Is the output scaling of the values that come in for all the PIDs referenced within the code as well? Or is that information obtained from another source?

[Chris@HPTuners]

it's not in the code. Most of the factors are usually powers of 2 or factors of 10 variation of those, some you can guess others you have to find from other sources - like our scanner

[aivikrames]

it's not in the code. Most of the factors are usually powers of 2 or factors of 10 variation of those, some you can guess others you have to find from other sources - like our scanner

How exactly would I go about finding them with your scanner (I take it the scan tool part, not the tuning)?

[FastFieros]

I have searched in the scanner settings and see nothing that indicates I can get formula's or calulations.

What about sensor values? The IAT is 0-10000 ohms. A resistor value of 3.3K in the wiring will give 69 degrees. Sometimes its 72 however.

Its like the IAT values. When you want the happy knob. I see it now I think.

However this thought comes from the EDITOR not the scanner.

This pic shows the scaling


Can a calulation be made from the top numbers to the side numbers?

Loyde

[aivikrames]

I have searched in the scanner settings and see nothing that indicates I can get formula's or calulations.

What about sensor values? The IAT is 0-10000 ohms. A resistor value of 3.3K in the wiring will give 69 degrees. Sometimes its 72 however.

Its like the IAT values. When you want the happy knob. I see it now I think.

However this thought comes from the EDITOR not the scanner.

This pic shows the scaling


Can a calulation be made from the top numbers to the side numbers?

Loyde

Actually, I believe what we are looking for are the scaling values from the scanner or editor. Acutal formulas possibly could be formulated, but that could be pretty tough.

With the scaling values, we can determine within the disassembled code the actual formula. Here is an example:

------------------------------------------------------------------------
Line1: move.w ($FFFFA390).w,d0
Line2: mulu.w #$D,d0
Line3: divu.w #$105,d0
Line4: rts
------------------------------------------------------------------------

Line 1 = $FFFFA390. The scaling value for this is between 0 and 100, because it is a percent. With that we can determine the value will fall between 00 - FF (Hex) which is 00 - 255. So use the max FF (255) for line 1.

Then quoting Chris, this is how you find the forumla in the bin file:

Firstly, you need to know the output scaling of the values that come in the PIDs. For TPS% i can tell you that it is a single byte that ranges from 0-100%. So you know that a raw value of 255 = 100% TPS. Then you just work backwards to work out the RAM scalar. eg. for TPS it works out as (255/100) * 261 / 13 = 51.2

So in RAM the PCM stores the TPS% value as x 51.2 (ie. 100% = 5120 ($1400)

Generally it is easy to see the maximum value of various RAM values in the code as there is a lot of range checking.

The scaling value is used in line 1 (FFFFA390) of the bin formula for pid 1151. Hence FFFFA390 = 255 / 100 (The divide by 100 confuses me, but I guess since it is a percent that is why it is divided by 100). Then from there you just plug the rest of the formula in and you get the conversion value.

[aivikrames]

Maybe Chris can answer this:

------------------------------------------------------------------------
Line1: move.w ($FFFFA390).w,d0
Line2: mulu.w #$D,d0
Line3: divu.w #$105,d0
Line4: rts
------------------------------------------------------------------------
Why in this formula does D (13) come before 105 (261), but in the actual formula 105 is used before D. Yet, the operators stay in the same place? I noticed for PID 1141, that it follows a straight top down approach where the operations are placed directly on the words, and not reversed. Why is that?

seg1b:0003F60E ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦
seg1b:0003F60E
seg1b:0003F60E
seg1b:0003F60E PID1141_IGNV_code: ; DATA XREF: Seg1a:00002104o
seg1b:0003F60E move.w (IGNVx256).w,d0 ; IGNV x 256 ($C00 = 12V)
seg1b:0003F612 mulu.w #5,d0 ; x 5
seg1b:0003F616 cmpi.l #$FFFF,d0
seg1b:0003F61C bhi.s loc_3F626
seg1b:0003F61E lsr.w #7,d0 ; / 128 .... (256 x 5 / 128 = x 10)
seg1b:0003F620 cmpi.w #$FF,d0
seg1b:0003F624 bls.s locret_3F62A
seg1b:0003F626
seg1b:0003F626 loc_3F626: ; CODE XREF: PID1141_IGNV_code+Ej
seg1b:0003F626 move.b #-1,d0
seg1b:0003F62A
seg1b:0003F62A locret_3F62A: ; CODE XREF: PID1141_IGNV_code+16j
seg1b:0003F62A rts ; d0 = IGNV x 10
seg1b:0003F62A ; End of function PID1141_IGNV_code

[FastFieros]

Wish I was smart enough to read assembly in IDA. I do some great guesssing that has worked for me.

Anyway, one thing that Ken and Chris have noted many times on this forum, is that IDA displays too many F's in its addresses. Not sure this is effecting your thoughts on how this stuff moves around in the code.

Loyde

[Chris@HPTuners]

Maybe Chris can answer this:

------------------------------------------------------------------------
Line1: move.w ($FFFFA390).w,d0
Line2: mulu.w #$D,d0
Line3: divu.w #$105,d0
Line4: rts
------------------------------------------------------------------------
Why in this formula does D (13) come before 105 (261), but in the actual formula 105 is used before D. Yet, the operators stay in the same place? I noticed for PID 1141, that it follows a straight top down approach where the operations are placed directly on the words, and not reversed. Why is that?

just the way i typed it

In your example $FFFFA390 is the TPS RAM value (ie. where the PCM stores the value of the TPS%)

this is stored as x 51.2

If you take 51.2 x 13 / 261 you get 2.55 which is the PID scaled version of the RAM value to fit in one byte (with the obvious resolution penalty).

Many PIDs are scaled to fit either one or two bytes.

[aivikrames]

just the way i typed it

In your example $FFFFA390 is the TPS RAM value (ie. where the PCM stores the value of the TPS%)

this is stored as x 51.2

If you take 51.2 x 13 / 261 you get 2.55 which is the PID scaled version of the RAM value to fit in one byte (with the obvious resolution penalty).

Many PIDs are scaled to fit either one or two bytes.

Ahh, now that makes sense. I was scratching my head trying to figure out where the 2.55 came from. Thanks.